I'd like to give my opinion, since I have some experience with Docker.
I am not sure what this PR tries to accomplish, so maybe some of my assumptions are wrong. If you point me out to the issues or discussions that explain the need for this PR, I would appreciate.

The first thing that I notice is that you don't need SSH to get a shell (bash) inside the container. The way that it is done, you basically open the SSH ports 4322 and 4222 to everyone that can access your computer. I don't think this is intended. Maybe your computer is safe and isolated from the world, maybe you can block those ports on the firewall (by default all docker ports are open, even if you have a firewall installed on your computer). But why open those ports on the first place, if it is not necessary.

The second thing is that docker usually needs root permissions to run. If it is an option, than I would prefer Podman instead of Docker, since it is daemon-less and root-less.

The third issue is that it is not easy to work inside a container for development. For example, if I use Emacs then I have to install and setup it inside the container. A better approach would be to share a host directory with the container (mount it inside the container). This way I can do the editing/development in the host, using my normal environment and setup, and use the container only for compilation, testing, etc. (since all the needed dependencies are included inside the container).

The last thing is that I don't see (in Dockerfiles) the dependencies for building/generating the docs.

I'd like to give my opinion, since I have some experience with Docker. I am not sure what this PR tries to accomplish, so maybe some of my assumptions are wrong. If you point me out to the issues or discussions that explain the need for this PR, I would appreciate.

No discussion or PR, I just felt like doing it :)

Goal is minimal live images for test driving BRL-CAD (user) or for connecting VS-Code to and compiling with minimal setup (there used to be something like this for GSoC, IIRC).

The first thing that I notice is that you don't need SSH to get a shell (bash) inside the container. The way that it is done, you basically open the SSH ports 4322 and 4222 to everyone that can access your computer. I don't think this is intended. Maybe your computer is safe and isolated from the world, maybe you can block those ports on the firewall (by default all docker ports are open, even if you have a firewall installed on your computer). But why open those ports on the first place, if it is not necessary.

intended and necessary for vs-code, afaik. Securing is a site configuration task

The second thing is that docker usually needs root permissions to run. If it is an option, than I would prefer Podman instead of Docker, since it is daemon-less and root-less.

docker is the most common and the images are consumable by singularity. Nothing precludes multiple container solutions

The third issue is that it is not easy to work inside a container for development. For example, if I use Emacs then I have to install and setup it inside the container. A better approach would be to share a host directory with the container (mount it inside the container). This way I can do the editing/development in the host, using my normal environment and setup, and use the container only for compilation, testing, etc. (since all the needed dependencies are included inside the container).

I believe emacs can do C-x C-f /ssh for remote, but the target audience is more "newbie" oriented and VS-Code is the new hotness
Mounting a local dir as a volume is a site configuration task, just modify the appropriate docker-compose.yaml

The last thing is that I don't see (in Dockerfiles) the dependencies for building/generating the docs.

doxygen is installed, both man and html documentation is generated. I did not include LaTeX due to size. Which docs are unable to build?

No discussion or PR, I just felt like doing it :)

Maybe the description of the PR (initial comment) could have been a bit more elaborate, for the benefit of newbies like me who don't know what is a VS-Code or an IIRC :)

doxygen is installed, both man and html documentation is generated. I did not include LaTeX due to size. Which docs are unable to build?

If it is intended just for testing or development then building the docs maybe is not needed.
If docker is used to build a release, then building the docs is probably required (as far as I know).

Unless you have been living under a rock for the past few months, probably you know that there has been an effort to build a new documentation system based on Antora:

• https://github.com/BRL-CAD/brlcad-docs
• https://brl-cad.fs.al/

Maybe the description of the PR (initial comment) could have been a bit more elaborate, for the benefit of newbies like me who don't know what is a VS-Code or an IIRC :)

ah, I misread PR as problem report, not pull request... to long in a foreign land.

If it is intended just for testing or development then building the docs maybe is not needed. If docker is used to build a release, then building the docs is probably required (as far as I know).

Unless you have been living under a rock for the past few months, probably you know that there has been an effort to build a new documentation system based on Antora:

• https://github.com/BRL-CAD/brlcad-docs
• https://brl-cad.fs.al/

must've been under a rock, this is news to me. My thought was more "tire-kicking". Using a container for production releases appeals to me, I use a singularity image to generate candidate releases for work, not sure how the current release sequence goes these days. node and a package shouldn't be difficult to add in if appropriate at this time, or can be done later.

I'm considering using a 'build script' to reduce the number of layers, thoughts? (I mostly just use docker images, singularity is my go-to... :) all ears to any new docker best practices, tips, tricks, etc)

I'm considering using a 'build script' to reduce the number of layers, thoughts?

I don't see any advantage from reducing the number of image layers. The real advantage might be that Dockerfile does not have a good support for scripting, while running a build script is cleaner and more flexible. However most of docker images don't need complex scripting.

all ears to any new docker best practices, tips, tricks, etc

I have used Docker mostly for installing web applications inside a container, so my experience maybe does not apply well to other cases.

I find useful to install systemd inside the Ubuntu or Debian images (systemd provides a modern version of /sbin/init). This way my containers behave like light-weight virtual machines. I can install several daemons inside them (for example apache2, mariadb, cron, ssh, etc.) and I don't have to worry about starting them and keeping them running because systemd will take care of it.

However using systemd in a Docker container is a bit tricky, so I use some bash scripts to encapsulate and hide these tricks. These bash scripts provide some other useful functionality as well. This is an incomplete tutorial about them: https://docker-scripts.gitlab.io/
I am not sure if they are useful for your case (testing, development, building a release, etc.) But maybe you can "steal" any useful trick.

restructured for deployment
added some antora stuff
pushed to docker hub as erikgreenwald/brl-cad and erikgreenwald/brl-cad-dev
Iff this is something that should be, it should probably auto-push to hub under an org and be tied to the deployment scripts/checklist.

Not sure if it should go in the code repo or if things are wired up right for modern BRL-CAD

I think that the Docker stuff should go into a separate repo, for example "BRL-CAD/docker". Most of the projects that I have seen handle it separately.

I think it's fine in misc/docker for now.. It's not unlike the other platform folders in there (and we are still monorepo when it comes to code). If it grows legs, it could just as easily be broken off later. It'd be nice to put this to use someplace active (maybe create jenkins runners for ci.brlcad.org).